c, cpp: add minimal Windows interop bindings - #26
Conversation
|
Validation update:
|
|
LLGo execution coverage is now automated on both host platforms: Both jobs build LLGo v1.0.0 with LLVM 19 and run all four Windows 11 ARM64 has also passed the same tests locally with the staged R8 integration. I additionally built and tested the latest merged LLGo Windows commit ( |
d1bee6f to
cda1bc5
Compare
There was a problem hiding this comment.
Review: minimal Windows interop bindings
This is a clean, well-scoped PR. The platform split into _default.go (!windows) and _windows.go files is consistent and the build constraints are mutually exclusive and complete — no GOOS is left without a definition, and no symbol is doubly defined. Struct layouts are notably well-verified: WSAData (386 vs 64, sizes 400/408), the Winsock Sockaddr*/Hostent/AddrInfo structs, _stat64 (size 56), and the release-mode MSVC std::string layout are all backed by explicit unsafe.Sizeof/Offsetof regression tests and a C++ static_assert. The C++ ABI is correctly kept behind a C shim (demangle_windows.cpp + extern "C"), and the returned char* ownership contract (caller frees) is matched by c.Free in the tests. No performance, memory-safety, or documentation-contradiction issues were found.
A few low-severity, non-blocking notes:
CI checks out a non-goplus org (xgo-dev/llgo) — .github/workflows/go.yml
The LLGo checkout points at xgo-dev/llgo, pinned to commit 6fc2ef150f95d8b9331433f325fcb1b6ee5ad4e4. The full-SHA pin is the right hardening (immutable, cannot be silently re-pointed), and this runs with a restricted token on pull_request with no secrets exposed. Worth confirming xgo-dev is the intended/trusted source and that the referenced stdcall support (xgo-dev/llgo#2433) is expected to land in the canonical repo before merge.
CanOnName field name — c/net/addrinfo_windows.go:17
Maps C ai_canonname. The name mis-splits the word ("can on name"), but it is intentional consistency with the pre-existing non-Windows declaration in c/net/net.go:212, not a new typo. Left as-is it keeps both platforms aligned; only worth touching if the awkward name is corrected in both files together (a public-API rename).
Header / build-tag style inconsistency (cosmetic)
New files mix the full Apache block header with the one-line Copyright ... Licensed under the Apache License 2.0. form, and a couple of files (c/stdio_windows.go, c/ctypes_windows.go) carry both //go:build and the legacy // +build lines while most use only //go:build. Worth normalizing to the repo standard.
Nothing here blocks the PR.
|
Replacement PR #27 targets goplus/lib directly and preserves this PR current squashed head as its first commit, with the LLVM 21 update as a separate second commit. |
…in-20260827 windows: support independent MSVC and MinGW profiles (R9, depends on goplus/lib#26)
Summary
Add only the native Windows C and C++ bindings currently required by the LLGo demo and compatibility-test suites:
stdcall.*namespacestd::stringlayout and wrappersThe package boundary remains platform-native. This PR does not emulate pthread, FLS, locks, semaphores, or Go closures on Windows. Existing POSIX pthread packages are simply excluded by Windows build constraints, and higher layers remain responsible for selecting a native thread implementation.
The non-Windows edits are limited to the build splits required to retain existing declarations and two ABI corrections exercised by the shared demos:
ctimereturnschar *, andfreeaddrinforeturnsvoid.Windows setjmp/longjmp are LLGo intrinsics so lowering occurs in the caller rather than in a wrapper frame that has already returned. The compiler support is already merged through xgo-dev/llgo#2425. Direct Winsock declarations use the stdcall support merged through xgo-dev/llgo#2433; this PR CI pins that merged xgo-dev/llgo commit and has no R9 dependency.
Validation
go test ./...on macOS ARM64c,c/math/rand,c/net,c/os,c/setjmp,c/time,cpp/llvm, andcpp/stdssagolden compilation passes with this commit used only by_demo/c,cl/_testlibc,cl/_testpy, andcl/_testrtThis work is part of the LLGo Windows support proposal.